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I. REAL PARTY IN INTEREST 

The real party in interest is the Assignee, Cypress Semiconductor Corporation, 

II. RELATED APPEALS AND INTERFERENCES 

There are no related appeals or interferences known to the Appellant, Appellant's legal 
representative, or Assignee which will directly affect or be directly affected by or have a bearing on 
the Board's decision in the pending appeal 

III, STATUS OF CLAIMS 

Claims 1-20 are pending and remain rejected. The Appellant hereby appeals the rejection 
of claims 1-20. 

IV. STATUS OF AMENDMENTS 

Appellant is appealing a final Office Action issued by the Examiner on May 3, 2005. On 
June 6, 2005, Appellant filed an Amendment After Final. On June 28, 2005, the Examiner issued 
an Advisory Action indicating that the Amendment After Final changes could not be entered. On 
August 3, 2005, Appellant filed (i) a Notice of Appeal and (ii) a Request for Review, both based on 
the claims prior to the Amendment After Final. On October 20, 2005, the Examiner issued a Notice 
of Panel Decision for Pre- Appeal Brief Review indicating that the case would proceed to the Board 
of Patent Appeals and Interferences. 
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V. SUMMARY OF CLAIMED SUBJECT MATTER 

A first embodiment of the present invention (as represented by claim 1) generally concerns 
a method of bridging an incoming packet (see FIG. 2) from a first network 104 to a second network 
106. The method may comprise a first step for (A) reading a pointer (e.g., signal POINTER) for a 
first parameter (e.g., MAC destination, MAC source, PDI, see FIG. 5) within the incoming packet. 
Blocks 150 and 152 (FIG. 4) generally illustrate reading a first parameter off an incoming packet. 
Once the parameter is found, the pointer may be read in the step 154 as discussed in the text on page 
17, lines 4-15. The step for reading may be implemented by a parser circuit 134 (FIG. 3) as 
described in the specification on page 14, lines 4-10. The method includes a second step for (B) 
processing the first parameter in accordance with the pointer to produce a second parameter. Blocks 
156 (FIG. 4) generally illustrate several example processing methods based on the pointer. The 
processing is generally described in the specification on page 17, lines 16-20. The step for 
processing may be implemented by a number of peripherals 132a-132q (FIG. 3), as described in the 
specification on page 14, line 1 1 through page 15, line 10. The method may include a third step for 
(C) presenting an outgoing packet containing the second parameter for the second network. Blocks 
158, 160 and 162 (FIG. 4) generally illustrate assembling an outgoing parameter, framing an 
outgoing frame and then transmitting the outgoing frame. The steps 158-162 are generally described 
in the specification on page 17, line 20 through page 18, line 3. The step for presenting may be 
implemented by an assembler circuit 136 as disclosed in the specification on page 15, lines 11-20. 

A second embodiment of the present invention (as represented by claim 16) generally 
concerns a circuit 126 in FIG. 3: The circuit generally comprises (A) a means for reading 134 (FIG. 
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3) a pointer (e.g., signal POINTER) for a first parameter (e.g f , MAC destination, MAC source, PDI, 
see FIG. 5) within an incoming packet compliant with a network protocol, (B) a means for 
processing 1 32a- 1 32q (FIG. 3) the first parameter in accordance with the pointer to produce a second 
parameter; and (C) a means for presenting 136 (FIG. 3) an outgoing packet containing the second 
parameter. The means for reading may be described in the specification on page 14, lines 4-10 and 
(referring to FIG.4) page 17, lines 4-15. The means for reading may be implemented as a protocol 
engine 126, a processing circuit 128 and/or a parser circuit 134. The means for processing may be 
described in the specification on page 14, line 11 through page 15, line 10, page 16, lines 1-17 and 
(referring to FIG. 4) page 17, lines 16-20. The means for processing may be implemented as a 
protocol engine 126, a processing circuit 128, an external peripheral circuit 108, peripheral circuits 
132a- 132q, dedicated hardware and/or programmable processors. The means for presenting may be 
described in the specification on page 15, lines 11-20 and (referring to FIG. 4) page 17, line 20 
through page 18, line 3. The means for presenting may be implemented as a protocol engine 126, 
a processing circuit 128 and/or an assembler circuit 146. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The first issue is whether claims 1-8 and 10-17 are patentable under 35 U.S.C. §102(e) over 
Ogawa et al. (hereafter Ogawa), U.S. Patent No. 5,936,966. 

The second issue is whether claim 9 is patentable under 35 U.S.C. § 103(a) over Ogawa in 
view of Official Notice that processing a first parameter in accordance with a pointer to produce a 
second parameter in a non-programming step is well known in the art. 
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The third issue is whether claims 1 8-20 are patentable under 35 U.S .C. § 103(a) over Ogawa 
in view of Wilford et al. (hereafter Wilford), U.S. Patent No. 6,687,247. 



VII. ARGUMENTS , 
A. 35 U.S.C § 102 

The Federal Circuit has stated that "[anticipation requires the presence in a single prior art 
reference disclosure of each and every element of the claimed invention, arranged as in the claim'' 1 
The Federal circuit has added that the anticipation determination is viewed from one of ordinary skill 
in the art: "There must be no difference between the claimed invention and the reference disclosure, 
as viewed by a person of ordinary skill in the field of the invention." 2 Furthermore, "A claim is 
anticipated only if each and every element as set forth in the claim is found, either expressly or 
inherently described, in a single prior art reference." 3 

1. Claims 1, 8, 10 and 12 are fully patentable over Ogawa 

Claim 1 provides a step for reading a pointer for a first parameter within an incoming packet 
. (from a first network). 4 In contrast, Ogawa does not disclose or suggest reading a pointer for a first 

l Lindemann Maschinenfabrik GmbH v. American Hoist & Derrick Co. , 22 1 USPQ 48 1 , 485 
(Fed. Cir. 1984) (emphasis added). 

2 Scripps Clinic & Research Found. V. Genentech Inc. , 927 F.2d 1565, 18U.S.P.Q.2d 1001, 
1010 (Fed. Cir. 1991). 

3 Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, USPQ2d 1051, 1053 (Fed 
Circ. 1987). 

4 Claim 1, preamble. 
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parameter within an incoming packet as presently claimed. The Examiner asserts 5 that column 13, 

lines 50-55 of Ogawa disclose a pointer similar to the claimed pointer: 

Incidentally, the TCP protocol information TC4 indicates an acknowledge number; the TCP 
protocol information TC5, an offset/flag; the TCP protocol information TC6, a window; 
the TCP protocol information TC8, an object pointer; and the TCP protocol information 
TC9, an optional field. (Emphasis added) 

While the Examiner does not specifically identify the pointer in the above text allegedly similar to 

the claimed pointer, the TCP protocol object pointer appears to be the only pointer mentioned. 

Therefore, the Examiner appears to allege that the TCP protocol object pointer of Ogawa is similar 

to the claimed pointer. 

The Examiner further asserts 6 that column 13, lines 15-21 of Ogawa discuss a parameter 

similar to the claimed first parameter within an incoming packet from a first network: 

Thereafter, the MAC header data MAH is received in accordance with WR1 to WR7. The 
MAC header data MAH is constituted by MAC address data MAA and protocol type 
data ET. In particular, a type of the following IP protocol can be identified by the protocol 
type data ET. In addition, MAC capsule data LL1 of DO is determined by the MAC address 
data MAA and the protocol type data ET. The MAC capsule data LL1 is output in 
synchronism with SB1 to SB4. (Emphasis added) 

While the Examiner does not specifically identify which element in the above text is allegedly 

similar to the claimed first parameter, the text appears to indicate that all of the above elements are 

part of a MAC header data. As such, the rest of the Appellant's argument will treat any element in 

the MAC header as allegedly similar to the claimed first parameter. 



5 Final Office Action, May 3, 2005, page 5, paragraph 8, line 6. 

6 Final Office Action, May 3, 2005, page 5, paragraph 8, lines 6-7. 
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Column 2, lines 5-8 of Ogawa state that the MAC layer is part of the second (data link) layer 
of the Open System Interconnection (OSI) model. In contrast, the object pointer in the TCP protocol 
is part of the fourth (transport) layer of the OSI model (see Appendix A, pages A-4 and A-5). 
Furthermore, the transport layer and the data link layer are not even adjoining layers in the OSI 
model. A network layer separates the transport layer from the data link layer. Therefore, one of 
ordinary skill in the art would not appear to understand the alleged pointer in the transport layer to 
be for the alleged parameter all the way down in the data link layer as required by Scripps Clinic & 
Research Found. Contrary to the assertion by the Examiner, the TCP object pointer of Ogawa 
appears to have no connection to the MAC header data of Ogawa. Therefore, Ogawa does not 
explicitly or inherently disclose a step for reading a pointer for a first parameter within an incoming 
packet as presently claimed. 

Claim 1 further provides a step for processing the first parameter in accordance with the 
pointer to produce a second parameter. The Examiner asserts 7 that Ogawa discusses processing the 
unidentified MAC header data element (asserted similar to the claimed first parameter) in accordance 
with the TCP object pointer (asserted similar to the claimed pointer) in column 13, lines 15-21, 
which have been reproduced above. However, nothing in the above Ogawa text appears to talk about 
processing any of the elements in the MAC header data in accordance with the TCP object pointer. 
Contrary to the Examiner's assertion, Ogawa appears to be silent regarding a step for processing a 
first parameter in accordance with a pointer to produce a second parameter as presently claimed. 



7 Final Office Action, May 3, 2005, page 5, paragraph 8, lines 9-10. 
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Claim 1 further provides that the processing of the first parameter in accordance with the 

pointer is to produce a second parameter. The Examiner asserts 8 that Ogawa discusses a parameter 

similar to the claimed second parameter in column 9, lines 7-24: 

Further, by outputting the destination network address as the retrieval key data signal 
SKD2, an entry having the same value as the output retrieval key data signal SKD2 in the 
network address field can be found in each entry of the retrieval table, and it is possible to 
obtain a PID with which a host computer that is to receive the data frame and a MAC 
address of that computer by reading that entry. In addition, if a CAM having the retrieval 
table configuration of which is shown in FIG. 6 is used as the external circuit, judgment is 
made upon whether the data frame is to be relayed to enable the firewall to be constructed 
by outputting the transport layer protocol code, the transport layer port number, the source 
network address and the destination network address as the retrieval key data signal SKD2 
and retrieving whether entries having the same data exist in the table. In this judgment, 
relay may be enabled if entries having the same data exist in the table, or it may be enabled 
if entries having the same data do not exist in the table. 

The Examiner fails to identify which of the above elements is allegedly similar to the claimed second 

parameter. Furthermore, none of the above elements of Ogawa, or any other elements of Ogawa, 

appear to be the product of some unidentified processing of an unidentified MAC header data 

element (asserted similar to the claimed first parameter) in accordance with the TCP object pointer 

(asserted similar to the claimed pointer). Therefore, Ogawa does not explicitly or inherently disclose 

a step for processing a first parameter in accordance with a pointer to produce a second parameter 

as presently claimed. 

Claim 1 further provides a step for presenting an outgoing packet containing the second 
parameter for a second network. The Examiner asserts 9 that column 8, lines 50-63 of Ogawa 



8 Final Office Action, May 3, 2005, page 5, paragraph 8, lines 1 1-12. 

9 Final Office Action, May 3, 2005, page 5, paragraph 8, lines 11-13. 
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mention presenting an outgoing packet on a second network containing the unidentified element 

allegedly similar to the claimed second parameter: 

...a retrieval sequencer 25B which is started up by a control signal SEC from the sequencer 
32, executes the retrieval operation with respect to the external CAM circuit by outputting 
the retrieval data selection signal and the SCK2, changes a sequence for retrieval using the 
HIT signal output from the CAM and directs a later-described retrieval result register 25C 
to store/hold a retrieval result reading signal by outputting a retrieval result holding signal; 
and a retrieval result register 25C which stores/holds the retrieval result reading signal in 
response to the direction from the retrieval sequencer 25B and can be read by the external 
CPU as a part of the capture register circuit 24. 

The retrieval key data signal SDK2 and the retrieval data synchronizing signal SCK2 are 
used to output a destination address of the received frame data to the external circuit 40 for 
executing various processes outside. 

The only element in the above text common to the text of Ogawa in column 9, lines 7-24 (source of 

the alleged second parameter) appears to be the retrieval key data signal SDK2. However, nothing 

in the above text, or in any other section of Ogawa appears to mention the retrieval key data signal 

SDK2 being part of an outgoing packet on some unidentified second network. Therefore, Ogawa 

does not explicitly or inherently disclose a step for presenting an outgoing packet containing a 

second parameter for a second network as presently claimed. 

In summary, Ogawa does not explicitly or inherently disclose (A) reading a pointer for a first 

parameter within an incoming packet, (B) processing the first parameter in accordance with the 

pointer to produce a second parameter and (C) presenting an outgoing packet containing the second 

parameter for a second network. The rejections appear to be a series of unrelated paragraphs that 

do not arrange the elements as claimed as required by Verdegaal Bros. As such, anticipation has not 

been established and the rejection should be reversed. 
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2. Claim 16 is fully patentable over Ogawa 

Claim 16 provides a means for reading a pointer for a first parameter within an incoming 
packet compliant with a network protocol. In contrast, Ogawa does not disclose or suggest a means 
for reading a pointer for a first parameter within an incoming packet as presently claimed. The 
Examiner asserts 10 that column 13, lines 50-55 of Ogawa disclose a pointer similar to the claimed 
pointer: 

Incidentally, the TCP protocol information TC4 indicates an acknowledge number; the TCP 
protocol information TC5, an offset/flag; the TCP protocol information TC6, a window; 
the TCP protocol information TC8, an object pointer; and the TCP protocol information 
TC9, an optional field. (Emphasis added) 

While the Examiner does not specifically identify the pointer in the above text allegedly similar to 

the claimed pointer, the TCP protocol object pointer appears to be the only pointer mentioned. 

Therefore, the Examiner appears to allege that the TCP protocol object pointer of Ogawa is similar 

to the claimed pointer. However, Ogawa appears to be silent regarding a circuit structure within the 

data receiving device (all of FIG. 1) that explicitly reads the TCP protocol object pointer. Therefore, 

Ogawa does not explicitly or inherently disclose a means for reading a pointer as presently claimed. 

The Examiner further asserts 11 that column 13, lines 15-21 of Ogawa discuss a parameter 

similar to the claimed first parameter within an incoming packet from a first network: 

Thereafter, the MAC header data MAH is received in accordance with WR1 to WR7. The 
MAC header data MAH is constituted by MAC address data MAA and protocol type 
data ET. In particular, a type of the following IP protocol can be identified by the protocol 
type data ET. In addition, MAC capsule data LL1 of DO is determined by the MAC address 



10 Final Office Action, May 3, 2005, page 5, paragraph 8, line 6. 

11 Final Office Action, May 3, 2005, page 5, paragraph 8, lines 6-7. 
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data MAA and the protocol type data ET. The MAC capsule data LL1 is output in 
synchronism with SB1 to SB4. (Emphasis added) 

While the Examiner does not specifically identify which element in the above text is allegedly 

similar to the claimed first parameter, the text appears to indicate that all of the above elements are 

part of a MAC header data. As such, the rest of the Appellant's argument will treat any element in 

the MAC header as allegedly similar to the claimed first parameter. 

Column 2, lines 5-8 of Ogawa state that the MAC layer is part of the second (data link) layer 
of the Open System Interconnection (OSI) model. In contrast, the object pointer in the TCP protocol 
is part of the fourth (transport) layer of the OSI model (see Appendix A, pages A-4 and A-5). 
Furthermore, the transport layer and the data link layer are not even adjoining layers in the OSI 
model. A network layer separates the transport layer from the data link layer. Therefore, one of 
ordinary skill in the art would not appear to understand the alleged pointer in the transport layer to 
be for the alleged parameter all the way down in the data link layer as required by Scripps Clinic & 
Research Found, Contrary to the assertion by the Examiner, the TCP object pointer of Ogawa 
appears to have no connection to the MAC header data of Ogawa. Therefore, Ogawa does not 
explicitly or inherently disclose a means for reading a pointer for a first parameter within an 
incoming packet as presently claimed. 

Claim 16 further provides a means for processing the first parameter in accordance with 
the pointer to produce a second parameter. The Examiner asserts 12 that Ogawa discusses processing 
the unidentified MAC header data element (asserted similar to the claimed first parameter) in 
accordance with the TCP object pointer (asserted similar to the claimed pointer) in column 13, lines 

12 Final Office Action, May 3, 2005, page 5, paragraph 8, lines 9-10. 
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15-21, which have been reproduced above. However, nothing in the above text of Ogawa appears 

to talk about a circuit structure of the data receiving device (all of FIG. 1) processing any of the 

elements in the MAC header data in accordance with the TCP object pointer. Contrary to the 

Examiner's assertion, Ogawa appears to be silent regarding a means for processing the first 

parameter in accordance with the pointer to produce a second parameter as presently claimed. 

Claim 16 further provides that the processing of the first parameter in accordance with the 

pointer is to produce a second parameter. The Examiner asserts 13 that Ogawa discusses a parameter 

similar to the claimed second parameter in column 9, lines 7-24: 

Further, by outputting the destination network address as the retrieval key data signal 
SKD2, an entry having the same value as the output retrieval key data signal SKD2 in the 
network address field can be found in each entry of the retrieval table, and it is possible to 
obtain a PID with which a host computer that is to receive the data frame and a MAC 
address of that computer by reading that entry. In addition, if a CAM having the retrieval 
table configuration of which is shown in FIG. 6 is used as the external circuit, judgment is 
made upon whether the data frame is to be relayed to enable the firewall to be constructed 
by outputting the transport layer protocol code, the transport layer port number, the source 
network address and the destination network address as the retrieval key data signal SKD2 
and retrieving whether entries having the same data exist in the table. In this judgment, 
relay may be enabled if entries having the same data exist in the table, or it may be enabled 
if entries having the same data do not exist in the table. 

The Examiner fails to identify which of the above elements is allegedly similar to the claimed second 

parameter. However, none of the above elements of Ogawa, or any other elements of Ogawa, appear 

to be the product of some unidentified processing of an unidentified MAC header data element 

(asserted similar to the claimed first parameter) in accordance with the TCP object pointer (asserted 

similar to the claimed pointer). Therefore, Ogawa does not explicitly or inherently disclose a means 



13 Final Office Action, May 3, 2005, page 5, paragraph 8, lines 1 1-12. 
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for processing a first parameter in accordance with a pointer to produce a second parameter as 
presently claimed. 

Claim 16 further provides a means for presenting an outgoing packet containing the second 
parameter. The Examiner asserts 14 that column 8, lines 50-63 of Ogawa mention presenting an 
outgoing packet containing the unidentified element allegedly similar to the claimed second 
parameter: 

...a retrieval sequencer 25B which is started up by a control signal SEC from the sequencer 
32, executes the retrieval operation with respect to the external CAM circuit by outputting 
the retrieval data selection signal and the SCK2, changes a sequence for retrieval using the 
HIT signal output from the CAM and directs a later-described retrieval result register 25C 
to store/hold a retrieval result reading signal by outputting a retrieval result holding signal; 
and a retrieval result register 25C which stores/holds the retrieval result reading signal in 
response to the direction from the retrieval sequencer 25B and can be read by the external 
CPU as a part of the capture register circuit 24. 

The retrieval key data signal SDK2 and the retrieval data synchronizing signal SCK2 are 
used to output a destination address of the received frame data to the external circuit 40 for 
executing various processes outside. 

The only element in the above text common to the text of Ogawa in column 9, lines 7-24 (source of 

the alleged second parameter) appears to be the retrieval key data signal SDK2. However, nothing 

in the above text, or in any other section of Ogawa appears to mention the retrieval key data signal 

SDK2 being part of an outgoing packet. Furthermore, the Examiner fails to identify any circuit 

structure element of Ogawa that allegedly presents outgoing packets. Therefore, Ogawa does not 

explicitly or inherently disclose a means for presenting an outgoing packet containing a second 

parameter as presently claimed. 



14 Final Office Action, May 3, 2005, page 5, paragraph 8, lines 11-13. 
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In summary, Ogawa does not explicitly or inherently disclose (A) a means for reading a 
pointer for a first parameter within an incoming packet, (B) a means for processing the first 
parameter in accordance with the pointer to produce a second parameter and (C) a means for 
presenting an outgoing packet containing the second parameter. The rejections appear to be a series 
of unrelated paragraphs that do not arrange the elements as claimed as required by Verdegaal Bros. 
As such, anticipation has not been established and the rejection should be reversed. 



3. Claim 2 is fully patentable over Ogawa 

Claim 2 depends from claim 1 and thus contains all of the limitations of claim 1. 
Consequently, the arguments presented above in support of the patentability of claim 1 are 
incorporated hereunder in support of claim 2. 

Claim 2 further provides a step for reading a length and an offset for the first parameter. The 

Examiner asserts 15 that Ogawa discusses reading a length and an offset for the unidentified MAC 

header data element (asserted similar to the claimed first parameter) in column 9, lines 27-65: 

FIG. 7 shows an example of a series of retrieval operations carried out by the second 
cut-through circuit 25 in a bridge, and FIGS. 8 through 10 show the operation of each 
signal. FIGS. 8 to 10 divide the continuously-lapsed operation into three for the 
convenience's sake. 

Also, FIG. 1 1 shows an example of a series of retrieval operations executed by the second 
cut-through circuit 25 in a router. 

The protocol recognition circuit 26 identifies a protocol type of each protocol hierarchy 
by comparing a protocol type represented by a protocol type signal PT input from the 
capture register circuit 24 or a protocol type indicated by the frame data FD2 output from 
the input data control circuit 22 with a predetermined protocol code for checking 
coincidence. 



15 Final Office Action, May 3, 2005, page 5, paragraph 9. 
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Here, the frame data FD2 directly input from the input data control circuit 22 to the 
protocol recognition circuit 26 is only of a network layer protocol type included in the 
MAC layer header. A code signal indicating a type of any higher protocol hierarchy, which 
was temporarily stored in the capture register 24A, is input to the protocol recognition 
circuit 26. That is because the code representing the network layer protocol corresponds to 
the end of the MAC header and, if it is stored in the capture register 24A, it will not be 
ready for the network layer header processing. 

Note that a result of recognition of a protocol type by the protocol recognition circuit 26 
is output to the sequence selection circuit 28 or the header end timing detection circuit 36 
as a protocol identification code signal PTN and also output to the external circuit such as 
a computer through the CPU bus as a protocol identification code signal PTN2. 

The sequence selection circuit 28 generates a sequence selection signal SES for selecting 
a process for each protocol hierarchy of the received frame data based on a result of 
recognition of a protocol type output from the protocol recognition circuit 26 and changes 
the sequence selection signal SES corresponding with each protocol hierarchy in 
accordance with a header end signal PHE output from the header end timing detection 
circuit 36. 

However, nowhere in the above text, or in any other section does Ogawa appear to discuss a length 
and an offset for any MAC header data element (alleged similar to the claimed first parameter). 
Therefore, Ogawa does not appear to explicitly of inherently disclose a step for reading a length and 
an offset for the first parameter as presently claimed. 

Claim 2 further provides a step for partitioning the incoming packet in accordance with the 
offset and the length to extract the first parameter prior to processing. The Examiner again asserts 16 
that the claimed partitioning step is discussed in the above reproduced text of Ogawa. However, 
nowhere in the above text, or in any other section does Ogawa appear to discuss partitioning an 
incoming packet in accordance with an unidentified offset and an unidentified length to extract an 
unidentified MAC header data element (asserted similar to the claimed first parameter). Therefore, 
Ogawa does not explicitly or inherently disclose a step for partitioning an incoming packet in 



Final Office Action, May 3, 2005, page 6, paragraph 9. 



Docket Number: 0325.00483 
Application No.: 09/881,367 



16 



accordance with an offset and a length to extract a first parameter prior to processing as presently 
claimed. As such, claim 2 is fully patentable over the cited reference and the rejection should be 
reversed. 



4. Claim 17 is fully patentable over Ogawa 

Claim 17 depends from claim 16 and thus contains all of the limitations of claim 16. 

Consequently, the arguments presented above in support of the patentability of claim 16 are 

incorporated hereunder in support of claim 17. 

Claim 1 7 further provides that the means for processing the first parameter comprises 

a means for partitioning the incoming packet. The Examiner asserts 17 that Ogawa discusses a means 

for partitioning an incoming packet in column 9, lines 27-65: 

FIG. 7 shows an example of a series of retrieval operations carried out by the second 
cut-through circuit 25 in a bridge, and FIGS. 8 through 10 show the operation of each 
signal. FIGS. 8 to 10 divide the continuously-lapsed operation into three for the 
convenience's sake. 

Also, FIG. 1 1 shows an example of a series of retrieval operations executed by the second 
cut-through circuit 25 in a router. 

The protocol recognition circuit 26 identifies a protocol type of each protocol hierarchy 
by comparing a protocol type represented by a protocol type signal PT input from the 
capture register circuit 24 or a protocol type indicated by the frame data FD2 output from 
the input data control circuit 22 with a predetermined protocol code for checking 
coincidence. 

Here, the frame data FD2 directly input from the input data control circuit 22 to the 
protocol recognition circuit 26 is only of a network layer protocol type included in the 
MAC layer header. A code signal indicating a type of any higher protocol hierarchy, which 
was temporarily stored in the capture register 24A, is input to the protocol recognition 
circuit 26. That is because the code representing the network layer protocol corresponds to 
the end of the MAC header and, if it is stored in the capture register 24A, it will not be 
ready for the network layer header processing. 



17 Final Office Action, May 3, 2005, page 6, paragraph 9. 
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Note that a result of recognition of a protocol type by the protocol recognition circuit 26 
is output to the sequence selection circuit 28 or the header end timing detection circuit 36 
as a protocol identification code signal PTN and also output to the external circuit such as 
a computer through the CPU bus as a protocol identification code signal PTN2. 

The sequence selection circuit 28 generates a sequence selection signal SES for selecting 
a process for each protocol hierarchy of the received frame data based on a result of 
recognition of a protocol type output from the protocol recognition circuit 26 and changes 
the sequence selection signal SES corresponding with each protocol hierarchy in 
accordance with a header end signal PHE output from the header end timing detection 
circuit 36. 

The above text of Ogawa appear to discuss protocol recognition, but is silent regarding partitioning 
an incoming packet. Furthermore, nowhere in the above text, or in any other section does Ogawa 
appear to discuss that some unidentified means for partitioning is part of an unidentified means for 
processing MAC header elements (alleged similar to the claimed first parameter). Therefore, Ogawa 
does not explicitly or inherently disclose a means for processing the first parameter comprising a 
means for partitioning the incoming packet as presently claimed. As such, claim 17 is fully 
patentable over the cited reference and the rejection should be reversed. 



5. Claim 3 is fully patentable over Ogawa 

Claim 3 depends from claim 2 and thus contains all of the limitations of claim 2. 
Consequently, the arguments presented above in support of the patentability of claim 2 are 
incorporated hereunder in support of claim 3. 
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Claim 3 further provides a step for downloading the offset, the length, and the pointer prior 

to reading (a pointer for a first parameter) 18 . The Examiner asserts 19 that a step similar to the claimed 

downloading is discussed by Ogawa in column 9, lines 27-65: 

FIG. 7 shows an example of a series of retrieval operations carried out by the second 
cut-through circuit 25 in a bridge, and FIGS. 8 through 10 show the operation of each 
signal. FIGS. 8 to 10 divide the continuously-lapsed operation into three for the 
convenience's sake. 

Also, FIG. 1 1 shows an example of a series of retrieval operations executed by the second 
cut-through circuit 25 in a router. 

The protocol recognition circuit 26 identifies a protocol type of each protocol hierarchy 
by comparing a protocol type represented by a protocol type signal FT input from the 
capture register circuit 24 or a protocol type indicated by the frame data FD2 output from 
the input data control circuit 22 with a predetermined protocol code for checking 
coincidence. 

Here, the frame data FD2 directly input from the input data control circuit 22 to the 
protocol recognition circuit 26 is only of a network layer protocol type included in the 
MAC layer header. A code signal indicating a type of any higher protocol hierarchy, which 
was temporarily stored in the capture register 24A, is input to the protocol recognition 
circuit 26. That is because the code representing the network layer protocol corresponds to 
the end of the MAC header and, if it is stored in the capture register 24A, it will not be 
ready for the network layer header processing. 

Note that a result of recognition of a protocol type by the protocol recognition circuit 26 
is output to the sequence selection circuit 28 or the header end timing detection circuit 36 
as a protocol identification code signal PTN and also output to the external circuit such as * 
a computer through the CPU bus as a protocol identification code signal PTN2. 

The sequence selection circuit 28 generates a sequence selection signal SES for selecting 
a process for each protocol hierarchy of the received frame data based on a result of 
recognition of a protocol type output from the protocol recognition circuit 26 and changes 
the sequence selection signal SES corresponding with each protocol hierarchy in 
accordance with a header end signal PHE output from the header end timing detection 
circuit 36. 

However, nowhere in the above text, or in any other section does Ogawa appear to discuss a step for 
downloading an offset, a length and a pointer. In particular, Ogawa does not even use the word 



Claim 1, step (A). 
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"download". Therefore, Ogawa does not explicitly or inherently disclose a step for downloading the 
offset, the length, and the pointer prior to reading as presently claimed. 

Assuming, arguendo, that Ogawa does somehow discuss downloading (for which 
Appellant's representative does not necessarily agree), Ogawa is still silent regarding the 
downloading taking place prior to the alleged reading of the of the TCP object pointer (asserted 
similar to the claimed pointer) for a first parameter. Therefore, Ogawa does not expressly or 
inherently disclose a step for downloading the offset, the length, and the pointer prior to reading as 
presently claimed. As such, claim 3 is fully patentable over the cited reference and the rejection 
should be reversed. 

6. Claims 4 and 6 are fully patentable over Ogawa 

Claims 4 and 6 depend from claim 1 and thus contains all of the limitations of claim 1. 
Consequently, the arguments presented above in support of the patentability of claim 1 are 
incorporated hereunder in support of claims 4 and 6. 

Claim 4 further provides a step for routing the first parameter to at least one of a plurality 

of peripheral blocks identified by the pointer prior to processing (the first parameter) 20 , wherein the 

peripheral blocks perform the processing. The Examiner asserts 21 that the claimed step for routing 

to a peripheral block identified by the pointer is discussed by Ogawa in column 3, lines 44-65: 

In a data receiving device for receiving from a network frame data based on any arbitrary 
protocol of a plurality of protocol hierarchies defined from a physical layer to upper layers, 

20 Claim 1, step (B). 

21 Final Office Action, May 3, 2005, page 6, paragraph 11. 
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the present invention solves the above-described drawbacks by comprising: an input data 
control circuit for receiving the frame data together with its synchronizing signals from the 
network and holding them in a register; a capture register circuit for storing/holding in 
accordance with information such as a protocol type code, a header length, a frame length 
(network layer only), source/destination addresses or source/destination port or socket 
numbers included in a header for each protocol hierarchy constituting the frame data; a 
protocol recognition circuit for identifying a protocol type of each protocol hierarchy from 
the protocol type code stored in the capture register circuit; a sequence selection circuit 
which generates a sequence selection signal for selecting a processing for each protocol 
hierarchy of the recessed frame data in accordance with a result of identification by the 
protocol recognition circuit and changing the sequence selection signal in accordance with 
a header end signal; a sequence counter for counting a pulse signal in the frame data 
synchronizing signal; 

However, nowhere in the above text, or in any other section does Ogawa appear to discuss routing 

an unidentified MAC header data element (asserted similar to the claimed first parameter) to an 

unidentified peripheral block identified by the TCP object pointer (asserted similar to the claimed 

pointer). Therefore, Ogawa does not explicitly or inherently disclose a step for routing the first 

parameter to at least one of a plurality of peripheral blocks identified by the pointer prior to 

processing as presently claimed. 

Claim 4 further provides the routing, wherein the peripheral blocks perform the processing. 

In contrast, the Examiner asserts 22 that the processing of the first parameter in the peripheral block 

is discussed in Ogawa in column 4, lines 44-60: 

In addition, if the input data control circuit includes a first cut-through circuit for outputting 
the frame data synchronizing signal outside according a direction of a first cut-through 
signal output from the sequencer and for outputting outside a content of a specific register 
in the input data control circuit according to the first cut-through signal in synchronism 
with the frame data synchronizing signal, source/destination addresses and others included 
in the header of each protocol hierarchy of the received data frame can be selectively 
fetched and output to external circuits. Therefore, information required in a destination of 
linking to which the received data frame is transmitted or for the repeating process can be 
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fetched at high speed by using a retrieval table formed by a CAM (Contents Addressable 
Memory), a RAM (Random Access Memory) and others in an external circuit and 
executing table retrieval using the output as key data for retrieval. 

However, nowhere in the above text, or in any other section does Ogawa appear to discuss a 

peripheral block processing an unidentified MAC header data element (asserted similar to the 

claimed first parameter). Nowhere in the above text, or in any other section does Ogawa appear to 

discuss a plurality of peripheral blocks for performing processing. Therefore, Ogawa does not 

appear to explicitly or inherently disclose a step for routing the first parameter to at least one of a 

plurality of peripheral blocks identified by the pointer prior to processing, wherein the peripheral 

blocks perform the processing as presently claimed. As such, claim 4 is fully patentable over the 

cited reference and the rejection should be reversed. 

7. Claim 5 is fully patentable over Ogawa 

Claim 5 depends from claim 4 and thus contains all of the limitations of claim 4. 
Consequently, the arguments presented above in support of the patentability of claim 4 are 
incorporated hereunder in support of claim 5. 

Claim 5 further provides a step for reading a second offset and a second length for a second 

network protocol prior to assembling an outgoing packet. The Examiner asserts 23 that Ogawa 

discusses reading a second offset for a second network protocol in page (column) 10, lines 19-67: 

The sequencer 32 is provided with a plurality of processing sequences corresponding with 
various types of protocols of a plurality of protocol hierarchies, and selects one from a 
plurality of the processing sequences in accordance with a sequence selection signal SES 
output from the sequence selection circuit 28 and executes the selected sequence according 

23 Final Office Action, May 3, 2005, page 6, paragraph 12. 
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to a sequence counter signal CT output from the sequence counter 30. The sequencer 32 
directs a timing at which information of a protocol type code, a header length, 
source/destination addresses, source/destination port numbers and others included in the 
header of each protocol hierarchy is stored/held to the capture register circuit 24 by 
executing the selected sequence to output a sequence control signal SEC, and outputs a 
second header end timing indicating the end timing for the header if the currently-executed 
protocol possesses the header having a fixed length. Further, the sequencer 32 directs the 
input data control circuit 22 to output a value stored in a predetermined register within the 
circuit 22 as a retrieval key data signal SKD to the external circuit 40 together with the 
synchronizing signal SCK relative to the retrieval key data signal SKD by outputting the 
sequence control signal SEC. Furthermore, by outputting the sequence control signal SEC, 
the sequencer 32 directs the capture register circuit 24 to output data stored/held by a 
predetermined register within the capture register 24A as a retrieval data signal SKD2 to 
the external circuit 40 together with the synchronizing signal SCK relative to the retrieval 
key data SKD2. 

The header end timing detection circuit 36 selects either the first header end timing 
obtained by comparing a value of the sequence counter signal CT fed from the sequence 
counter 30 with a value (of a header length signal PHL) to be stored in a header length 
register in the capture register 24A of the currently-received protocol hierarchy or the 
second header end timing which is obtained by the process of the sequencer 32 and 
transmitted using the sequence control signal SEC, and generates a header end signal PHE. 

The header end timing detection circuit 36 may have a means for obtaining such a first 
header end timing and a means for obtaining such a second header end timing 
independently therein. In regard of a header having a fixed length, e.g., a header of the 
MAC protocol hierarchy or a header of the IPX protocol that is one protocol of the network 
hierarchy, the header end timing detection circuit 36 detects and uses the above-described 
second header end timing. On the other hand, as to a header which has an optional field and 
a variable length such as a header of the IP protocol that is one protocol of the network 
protocol hierarchy, the circuit 36 detects and adopts the first header end timing. 

However, nowhere in the above text, or in any other section does Ogawa appear to mention a second 

offset for a second network protocol. Therefore, Ogawa does not explicitly or inherently disclose 

a step for reading a second offset and a second length for a second network protocol prior to 

assembling an outgoing packet as presently claimed. As such, claim 5 is fully patentable over the 

cited reference and the rejection should be reversed. 
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8. Claim 7 is fully patentable over Ogawa 

Claim 7 depends from claim 1 and thus contains all of the limitations of claim 1. 
Consequently, the arguments presented above in support of the patentability of claim 1 are 
incorporated hereunder in support of claim 7. 

Claim 7 further provides that the step for processing the first parameter 24 is at least two 
processes of a content addressable memory process, a time to live process, a comparison process, 
a counter process, a value swapping process, a stuffing process, a de-stuffing process, a cyclic 
redundancy checksum process, a parity process, a first-in-first-out process, a length construction 
generator process, a header error control synchronization process, a frame relay lookup process, a 
data link connection identifier process, a protocol identification analysis process, a point-to-point 
protocol verification process, a parameter discard process, and a buffer process. The Examiner 
asserts 25 that at least two of the claimed processes are discussed by Ogawa in column 3, line 60 thru 
column 4, line 11: 

...a sequence selection signal for selecting a processing for each protocol hierarchy of the 
recessed frame data in accordance with a result of identification by the protocol 
recognition circuit and changing the sequence selection signal in accordance with a header 
end signal ; a sequence counter for counting a pulse signal in the frame data synchronizing 
signal; a sequencer which operates in response to a value of the sequence counter and the 
sequence selection signal and has a function for directing the capture register circuit a 
timing for storing/holding information included in the header for each protocol hierarchy 
and for outputting a second header end timing used to direct an end timing for the header 
when a protocol that is specified by the sequence selection signal and being processed has 
a header with a fixed length; and a header end timing detection circuit for selecting either 
a first header end timing obtained by comparing a value of the sequence counter with the 



24 Claim 1, step (B) 

25 Final Office Action, May 3, 2005, page 7, paragraph 14. 
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header length of the protocol hierarchy which is being received and [or] the second header 
end timing output by the sequencer to generate the header end signal. (Emphasis added) 

However, none of the processes in the above text appear to operate on an unidentified MAC header 

data element (asserted similar to the claimed first parameter). Therefore, Ogawa does not expressly 

or inherently disclose that a step for processing a first parameter is at least two processes of a content 

addressable memory process, a time to live process, a comparison process, a counter process, a value 

swapping process, a stuffing process, a de-stuffing process, a cyclic redundancy checksum process, 

a parity process, a first-in-first-out process, a length construction generator process, a header error 

control synchronization process, a frame relay lookup process, a data link connection identifier 

process, a protocol identification analysis process, a point-to-point protocol verification process, a 

parameter discard process, and a buffer process as presently claimed. As such, claim 7 is fully 

patentable over the cited reference and the rejection should be reversed. 

9. Claim 11 is fully patentable over Ogawa 

Claim 11 depends from claim 1 and thus contains all of the limitations of claim 1. 
Consequently, the arguments presented above in support of the patentability of claim 1 are 
incorporated hereunder in support of claim 11. 

Claim 1 1 further provides a step for selecting among a plurality of frame delineation methods 
for a plurality of network protocols prior to delineating. The Examiner asserts 26 that the claimed 
selecting step is discussed in Ogawa in column 7, line 54-column 8, line 12: 



26 Final Office Action, May 3, 2005, page 7, paragraph 17. 
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As shown in FIG. 3, the capture register circuit 24 is constituted by a plurality of capture 
registers 24A for a source MAC address, a destination MAC address, a network layer 
protocol, a source IP address, a destination IP address, a transport layer protocol, a source 
port number, a destination port number, receive port number (PID) and others. Although 
the present invention is not restricted to this structure in application, this embodiment has 
a source MAC register for storing/holding a source MAC address, a destination MAC 
register for storing/holding a destination MAC address and a network layer protocol 
register for storing/holding a network layer protocol as registers for storing/holding 
information included in the MAC layer header; a frame length register (network layer only) 
for storing/holding a frame length, a transport layer protocol register for storing/holding 
a protocol code of a transport layer, a source network address register for storing/holding 
a source network address, a destination network address register for storing/holding a 
destination network address, and a header length register for storing/holding a length of 
the network layer header as registers for storing/holding information included in the 
network layer header; and a source port register for storing/holding a source port number 
and a destination port register for storing/holding a destination port number as registers 
for storing/holding information included in the transport layer header. (Emphasis added) 

However, nowhere in the above text, or in any other section does Ogawa appear to discuss a step of 

selecting among a plurality of frame delineation methods for a plurality of network protocols. 

Furthermore, the above cited text appears to be no more than a list of registers, not a step for 

selecting. Therefore, Ogawa does not explicitly or inherently disclose a step for selecting among a 

plurality of frame delineation methods for a plurality of network protocols prior to delineating as 

presently claimed. As such, claim 1 1 is fully patentable over the cited reference and the rejection 

should be reversed. 



10. Claim 13 is fully patentable over Ogawa 

Claim 13 depends from claim 1 and thus contains all of the limitations of claim 1. 
Consequently, the arguments presented above in support of the patentability of claim 1 are 
incorporated hereunder in support of claim 13. 
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Claim 13 further provides a step for framing the outgoing packet to produce a transmit frame 

for the second network in response to presenting the outgoing packet. The Examiner asserts 27 that 

the claimed framing step is discussed by Ogawa in column 3, lines 44-65: 

In a data receiving device for receiving from a network frame data based on any arbitrary 
protocol of a plurality of protocol hierarchies defined from a physical layer to upper layers, 
the present invention solves the above-described drawbacks by comprising: an input data 
control circuit for receiving the frame data together with its synchronizing signals from the 
network and holding them in a register; a capture register circuit for storing/holding in 
accordance with information such as a protocol type code, a header length, a frame length 
(network layer only), source/destination addresses or source/destination port or socket 
numbers included in a header for each protocol hierarchy constituting the frame data; a 
protocol recognition circuit for identifying a protocol type of each protocol hierarchy from 
the protocol type code stored in the capture register circuit; a sequence selection circuit 
which generates a sequence selection signal for selecting a processing for each protocol 
hierarchy of the recessed frame data in accordance with a result of identification by the 
protocol recognition circuit and changing the sequence selection signal in accordance with 
a header end signal; a sequence counter for counting a pulse signal in the frame data 
synchronizing signal; 

However, nowhere in the above in the above text, or in any other section does Ogawa appear to 
discuss framing an outgoing packet to produce a transmit frame for a second network. In contrast, 
the cited text of Ogawa only appears to discuss how to receive an incoming packet. An ability to 
receive an incoming packet does not expressly or inherently suggest an ability to frame an outgoing 
packet. Therefore, Ogawa does not explicitly or inherently disclose a step for framing the outgoing 
packet to produce a transmit frame for the second network in response to presenting the outgoing 
packet as presently claimed. As such, claim 13 is fully patentable over the cited reference and the 
rejection should be reversed. 



27 Final Office Action, May 3, 2005, page 13, paragraph 19. 
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11. Claims 14 and 15 are fully patentable over Ogawa 



Claims 14 and 15 depend from claim 13 and thus contains all of the limitations of claim' 13. 
Consequently, the arguments presented above in support of the patentability of claim 13 are 
incorporated hereunder in support of claims 14 and 15. 

Claim 14 further provides a step for selecting among a plurality of framing methods for a 

plurality of network protocols prior to framing. The Examiner asserts 28 that the claimed selecting 

step is disclosed by Ogawa in column 10, lines 21-36: 

The sequencer 32 is provided with a plurality of processing sequences corresponding with 
various types of protocols of a plurality of protocol hierarchies, and selects one from a 
plurality of the processing sequences in accordance with a sequence selection signal SES 
output from the sequence selection circuit 28 and executes the selected sequence according 
to a sequence counter signal CT output from the sequence counter 30. The sequencer 32 
directs a timing at which information of a protocol type code, a header length, 
source/destination addresses, source/destination port numbers and others included in the 
header of each protocol hierarchy is stored/held to the capture register circuit 24 by 
executing the selected sequence to output a sequence control signal SEC, and outputs a 
second header end timing indicating the end timing for the header if the currently-executed 
protocol possesses the header having a fixed length. Further, the sequencer 32 directs the 
input data control circuit 22 to output a value stored in a predetermined register within the 
circuit 22 as a retrieval key data signal SKD to the external circuit 40 together with the 
synchronizing signal SCK relative to the retrieval key data signal SKD by outputting the 
sequence control signal SEC. (Emphasis added) 

The Examiner appears to be arguing that the sequencer 32 of Ogawa performs a step similar to the 

claimed selection step for a framing method. However, Ogawa states in column 6, lines 55-59 that 

the sequencer 32 is part of a first embodiment shown in FIG. 1. Ogawa further states in column 5, 

lines 47-49 that FIG. 1 "is a block diagram showing the structure of a first embodiment of a data 

receiving device" (emphasis added). One of ordinary skill in the art would appear to understand that 
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receiving devices deframe incoming information, not select among multiple framing methods for 
transmitting information. Therefore, Ogawa does not appear to explicitly or inherently disclose a 
step for selecting among a plurality of framing methods for a plurality of network protocols prior to 
framing as presently claimed. As such, claims 14 and 15 are fully patentable over the cited reference 
and the rejection should be reversed. 

B 35 U.S.C. § 103 

The Examiner bears the initial burden of factually supporting any prima facie conclusion of 
obviousness. 29 If the Examiner does not produce a, prima facie case, the Applicant is under no 
obligation to submit evidence of non-obviousness. 30 The Examiner must show that (a) there is some 
suggestion or motivation, either in the references or in the knowledge generally available to one of 
ordinary skill in the art, to modify or combine the references, (b) there is a reasonable expectation 
of success, and (c) the prior art reference (or combination of references) teaches or suggests all of 
the claim limitations? 1 "The motivation, suggestion or teaching may come explicitly from statement 
in the prior art, the knowledge of one of ordinary skill in the art, or, in some cases the nature of the 
problem to be solved." 32 Furthermore, The Court of Appeals for the Federal Circuit has indicated 



29 Manual of Patent Examining Procedure (M.P.E.P.), Eighth Edition, Rev. 3, August 2005, 

§2142. 

30 M.P.E.P. §2142. 

31 M.P.E.P. §2142. 

32 In re Huston 308, F.3d 1267, 1278, 64 USPQ2d 1810, 1810 (Fed. Cir; 2002), citing In re 
Katzab 217 F.3d 1365, 1370, 55 USPQ2d 1313, 1317 (Fed. Cir. 2000) 
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that the requirement for showing the teaching of motivation to combine references is "rigorous" and 
must be "clear and particular". 33 "[T]o establish obviousness based on a combination of the 
elements disclosed in the prior art, there must be some motivation, suggestion or teaching of the 
desirability of making the specific combination that was made by the applicants. " 34 "[T]he factual 
inquiry whether to combine references must be thorough and searching" 35 "This factual question 
... [cannot] be resolved on subjective belief and unknown authority." 36 "It must be based on 
objective evidence of record" 31 The Federal Circuit has held that both the suggestion to modify or 
combine the references and the reasonable expectation success must be found in the prior art itself, 
not merely in Appellant's disclosure. 38 Furthermore, the Board has held that the claimed invention 
is obvious only if either the references expressly or implicitly suggest the claimed invention, or a 
convincing line of reasoning is presented by the examiner as to why an artisan would have found the 
claimed invention to be obvious in light of the teachings of the cited references. 39 (Emphasis added) 



33 In re Anita Dembiczak and Benson Zinbarg, 50 U.S.P.Q.2d 1614 (Fed. Cir. 1999) 

34 In re Kotzab, 217 F.3d 1365, 1370, 55 USPQ2d 1313, 1316 (Fed. Cir. 2000) (citing In re 
Dance, 160 F.3d 1339, 1343, 48 USPQ2d 1635, 1637 (Fed. Cir. 1998); In re Gordon, 733 F.2d 900, 
902, 221 USPQ 1125, 1127 (Fed. Cir. 1984)). 

35 McGinleyv. Franklin Sports, Inc., 262F.3d 1339, 1351-52, 60USPQ2d 1001, 1008 (Fed. 
Cir. 2001). 

36 In re Lee, 211 F.3d 1338, 1343-44, 61 USPQ2d 1430, 1434 (Fed. Cir. 2002). 

37 In re Lee at 1343, 61 USPQ2d at 1434. 

38 See In re Vaeck, 947 F.2d 488, 20 U.S.P.Q.2d 1438, 1442 (Fed. Cir. 1991). 

39 See Ex Parte Clapp, 221 USPQ 972, 973 (Bd. Pat. App. & Inter. 1985) (emphasis added 
by Appellant). , 
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1. Claim 9 is fully patentable over Ogawa and Official Notice 

Claim 9 depends from claim 1 and thus contains all of the limitations of claim 1. 
Consequently, the arguments presented above in support of the patentability of claim 1 are 
incorporated hereunder in support of claim 9. 

The Examiner fails to establish a clear and particular showing of a teaching or motivation 
to modify Ogawa to make processing of the first parameter non-programmable. The alleged 
motivations provided by the Examiner (i) "to facilitate non-programmable processing", (ii) "enhance 
processing the steps taught by the Ogawa" and (iii) "help increase the degree of freedom of circuit 
design" 40 are not credited to any reference or knowledge generally available to one of ordinary skill 
per M.P.E.P. §2142. The alleged motivations are not credited to the nature of the problem to be 
solved per In re Huston. The alleged motivations are not based on objective evidence of record as 
required by In re Lee. Therefore, the alleged motivations are merely conclusory statements lacking 
the required supporting evidence. Furthermore, the fact that Yusa (U.S. Patent No. 5,633,806) 
teaches a concept does not explain why one of ordinary skill in the art would be motivated to modify 
Ogawa with that concept. The fact that references can be combined or modified is not sufficient to 
establish prima facie obviousness per M.P.E.P. §2143.01. As such, prima facie obviousness has not 
been established for lack of a clear and particular showing of a teaching or motivation to modify 
Ogawa with Official Notice as required by In re Anita Dembiczak. As such, claim 9 is fully 
patentable over the cited reference and Official Notice and thus the rejection should be reversed. 



40 



Final Office Action, May 3, 2005, page 9, paragraph 24. 



v Docket Number: 0325.00483 
Application No.: 09/881,367 31 



2. Claim 18 is fully patentable over Ogawa and Wilford 

Claim 18 depends from claim 17 and thus contains all of the limitations of claim 17. 
Consequently, the arguments presented above in support of the patentability of claim 17 are 
incorporated hereunder in support of claim 18. 

Claim 18 further provides that the means for processing (the first parameter) 41 comprises a 
plurality of peripheral means at least one (i) linked to the pointer and (ii) configured to perform a 
process involving the first parameter. The Examiner asserts 42 that modules of memory in figures 9, 
10, 15 and 26 of Wilford are similar to the claimed peripheral means. The Examiner further asserts 
that "information including header" 43 of Wilford is similar to the claimed first parameter and the 
"concept of TAG usage" 44 is similar to the claimed pointer. The Examiner also asserts 45 that the 
modules of memory from Wilford can perform a process involving a first parameter as described in 
column 6, lines 2-23: 

The packet is then enqueued normally in an output queue in the second linecard 110. 
Packets from the CPU that are to be sent via the same linecard are written back to the 
outbound queue manager 280 from CPU 440. 

Regular packets (i.e., those other than the one sent to the CPU) are sent to (inbound) 
fabric interface 170. Once the packets have been sent over switch fabric 120 and 
(outbound) fabric interface 170, they arrive at outbound receiver 260 in the outbound 
linecard. The outbound linecard may be in the same or a different linecard 110 than that 
discussed above. The conventional MAC rewrite is done by outbound receiver 260. Output 

41 Claim 16, step (B). 

42 Final Office Action, May 3, 2005, page 9, paragraph 26. 

43 Final Office Action, May 3, 2005, page 10, first line. 

44 Final Office Action, May 3, 2005, page 9, second to last line 

45 Final Office Action, May 3, 2005, page 9-10, paragraph 26. 
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rate pacing is performed in rate limiter 270 using, in one embodiment, algorithms similar 
to that used in the inbound path discussed above; in some embodiments, rate limiter 270 
is omitted and no rate pacing is performed. Outbound packets are then buffered and 
enqueued by outbound queue manager 280 using outbound packet buffer 285. Outbound 
queue manager 280 and outbound packet buffer 285 are configured and operate similarly 
to inbound queue manager 240 and its associated inbound packet buffer 245. 

However, nowhere in the above text, or in any other section does Wilford appear to discuss modules 

of memory processing "information including header" as alleged by the Examiner. Nowhere in the 

above text does Wilford even appear to even mention processing header information. Therefore, 

Ogawa and Wilford, alone or in combination, do not teach or suggest a means for processing 

comprising a plurality of peripheral means at least one (i) linked to the pointer and (ii) configured 

to perform a process involving the first parameter as presently claimed. As such, prima facie 

obviousness has not been established for failure to establish that the references teach all of the claim 

limitations as required by M.P.E.P. §2142. 

The Examiner fails to establish a clear and particular showing of a teaching or motivation 

to combine/modify Ogawa with Wilford. The alleged motivations provided by the Examiner to (i) 

"enhance the handling of information associated with the pointer", (ii) "help the software to process 

information for the circuit", (iii) enhance supporting information that is within the processing 

means", (iv) "enhance supporting information that is outside the processing means" and (v) "enhance 

handling of the information over the network according to the network protocol used" 46 are not 

credited to any reference or knowledge generally available to one of ordinary skill per M.P.E.P. 

§2142. The alleged motivations do not appear to arise from the nature of some problem to be solved 

per In re Huston. The alleged motivations are not based on objective evidence of record as required 

46 Final Office Action, May 3, 2005, page 10, paragraph 26 through page 11, paragraph 28. 
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by In re Lee. Therefore, the alleged motivation appear to be merely conclusory statements lacking 
the required supporting evidence. As such, prima facie obviousness has not been established for lack 
of a clear and particular showing of a teaching or motivation to modify Ogawa with Wilford as 
required by In re Anita Dembiczak. 

The Examiner fails to establish a reasonable expectation of success. The Examiner has not 
provided any explanation or evidence that one of ordinary skill in the art would understand how to 
combine and/or modify the MAC header data of Ogawa (asserted similar to the claimed first 
parameter) and the "information including header" of Wilford (also asserted similar to the claimed 
first parameter) to create some undefined first parameter within an incoming packet. The Examiner 
has not provided any explanation or evidence that one of ordinary skill in the art would understand 
how to combine and/or modify the TCP pointer of Ogawa (asserted similar to the claimed pointer) 
with the "concept of TAG usage" of Wilford (also asserted similar to the claimed pointer) to create 
some undefined pointer for the undefined first parameter. The Examiner has not provided any 
explanation or evidence that one of ordinary skill in the art would understand how to combine and/or 
modify the modules of memory from Wilford (asserted similar to the claimed peripheral means) to 
be linked to the undefined pointer. The Examiner has not provided any explanation or evidence that 
one of ordinary skill in the art would understand how to combine and/or modify the modules of 
memory of Wilford (asserted similar to the claimed peripheral means) to perform a process on the 
undefined first parameter. The Examiner merely alleges that combinations and/or modifications 
could be made, but fails (i) to identify what the actual combinations and/or modifications would look 
like and (ii) why there is a reasonable expectation for success. As such, prima facie obviousness has 
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not been established for lack evidence for a reasonable expectation of success as required by 
M.P.E.P. §2142. Since the Examiner has failed to establish a prima facie case, Appellant is under 
no obligation to establish non-obviousness per M.P.E.P. 2142. Therefore, the rejection of claim 18 
should be reversed. 

3. Claims 18 and 20 are fully patentable over Ogawa and Wilford 

Claims 19 and 20 depends from claim 18 and thus contains all of the limitations of claim 18. 
Consequently, the arguments presented above in support of the patentability of claim 18 are 
incorporated hereunder in support of claims 19 and 20. 

Claim 19 further provides that the peripheral means comprises a first plurality of the 
peripheral means internal to the means for processing and a second plurality of the peripheral means 
external to the means for processing. The Examiner asserts 47 that Wilford teaches external memory 
and internal memory. However, the Examiner fails to establish that the external memory of Wilford 
is in fact external to a circuit similar to the claimed means for processing a first parameter. The 
Examiner fails to establish that the internal memory of Wilford is in fact internal to a circuit similar 
to the claimed means for processing a first parameter. In particular, the Examiner fails to identify 
any circuit in either Ogawa or Wilford similar to the claimed means for processing the first 
parameter. Therefore, the Examiner's conclusion that a combination of Ogawa and Wilford would 
somehow teach all of (i) the claimed means for processing the first parameter, (ii) a first plurality of 
peripheral means internal to the means for processing and (iii) a second plurality of peripheral means 

47 Final Office Action, May 3, 2005, page 10, paragraph 27. 
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external to the means for processing appears to be improperly based on the claim language, not on 
some combination and/or modification that one of ordinary skill in the art would be motivated to 
make or find obvious. As such, prima facie obviousness has not been established for lack of 
evidence that the references teach all of the claim limitations as required by M.P.E.P. §2142. 
Therefore, the rejection of claims 19 and 20 should be reversed. 

C. CONCLUSION 

Ogawa does not explicitly or inherently disclose steps/means for (A) reading a pointer for 
a first parameter within an incoming packet, (B) processing the first parameter in accordance with 
the pointer to produce a second parameter and (C) presenting an outgoing packet containing the 
second parameter. Hence, the Examiner has clearly erred with respect to the patentability of the 
claimed invention. It is respectfully requested that the Board overturn the Examiner's rejection of 
all pending claims, and hold that the claims are not rendered obvious by the cited reference. 
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However, should the Board find the arguments herein in support of independent claims 1 and/or 16 
unpersuasive, the Board is respectfully requested to carefully consider the arguments set forth above 
in support of each of the independently patentable groups. 



Respectfully submitted, 



CHRISTOPHER P. MAIORANA, P.C. 




Dated: November 17. 2005 
24840 Harper Avenue 
Suite 100 

St. Clair Shores, MI 48080 
(586) 498-0670 
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^NOV 2 1 2005^ ^ n CLAIM APPENDIX 

^55*^^Kclaims of the present application which are involved in this appeal are as follows: 

1 1. A method of bridging an incoming packet from a first network to a second 

2 network, the method comprising the steps of: 

3 (A) reading a pointer for a first parameter within said incoming packet; 

4 (B) processing said first parameter in accordance with said pointer to produce a 

5 second parameter; and 

6 (C) presenting an outgoing packet containing said second parameter for said 

7 second network. 



1 2. The method according to claim 1, further comprising the steps of: 

2 reading a length and an offset for said first parameter; and 

3 partitioning said incoming packet in accordance with said offset and said length to 

4 extract said first parameter prior to processing. 

1 3 . The method according to claim 2, further comprising the step of downloading 

2 said offset, said length, and said pointer prior to reading. 
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1 ' 4. The method according to claim 1, further comprising the steps of: 

2 routing said first parameter to at least one of a plurality of peripheral blocks identified 

3 by said pointer prior to processing, wherein said peripheral blocks perform said processing; and 

4 assembling said second parameter into said outgoing packet in response to processing. 

1 5. The method according to claim 4, further comprising the step of reading a 

2 second offset and a second length for a second network protocol prior to assembling said outgoing 

3 packet. 

1 6. The method according to claim 4, further comprising the step of routing said 

2 first parameter to an external peripheral block identified by said pointer prior to processing, wherein 

3 said external peripheral block performs said processing. 

1 7. The method according to claim 1, wherein step (B) is at least two processes 

2 of a content addressable memory process, a time to live process, a comparison process, a counter 

3 process, a value swapping process, a stuffing process, a de-stuffing process, a cyclic redundancy 

4 checksum process, a parity process, a first-in-first-out process, a length construction generator 

5 process, a header error control synchronization process, a frame relay lookup process, a data link 

6 connection identifier process, a protocol identification analysis process, a point-to-point protocol 

7 verification process, a parameter discard process, and a buffer process. 
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1 '8. The method according to claim 1 , wherein step (B) comprises the sub-step of 

2 simultaneously processing a plurality of parameters within said incoming packet. 

1 9. The method according to claim 1, wherein step (B) is non-programmable. 

1 10. The method according to claim 1 , further comprising the step of delineating 

2 a receive frame from said first network to produce said incoming packet prior to processing. 

1 11. The method according to claim 10, further comprising the step of selecting 

2 among a plurality of frame delineation methods for a plurality of network protocols prior to 

3 delineating. 

1 12. The method according to claim 10, further comprising the step of delineating 

2 a second receive frame from said second network to produce said incoming packet. 

1 13. The method according to claim 1 , further comprising the step of framing said 

2 outgoing packet to produce a transmit frame for said second network in response to presenting said 

3 outgoing packet. 

1 14. The method according to claim 13, further comprising the step of selecting 

2 among a plurality of framing methods for a plurality of network protocols prior to framing. 
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1 15. The method according to claim 14, further comprising the step of framing said 

2 output packet to produce a second transmit frame for said first network in response to presenting said 

3 outgoing packet. 

1 16. A circuit comprising: 

2 means for reading a pointer for a first parameter within an incoming packet compliant 

3 with a network protocol; 

4 means for processing said first parameter in accordance with said pointer to produce 

5 a second parameter; and 

6 means for presenting an outgoing packet containing said second parameter. 

1 17. The circuit according to claim 16, wherein said means for processing 

2 comprises means for partitioning said incoming packet. 

1 18. The circuit according to claim 17, wherein said means for processing further 

2 comprises a plurality of peripheral means at least one (i) linked to said pointer and (ii) configured 

3 to perform a process involving said first parameter. 
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19. The circuit according to claim 18, wherein said plurality of peripheral means 
comprises a first plurality of said peripheral means internal to said means for processing and a 
second plurality of said peripheral means external to said means for processing. 

20. The circuit according to claim 19, further comprising means for interfacing 
to said first network configured to de-frame in compliance with a plurality of network protocols. 
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IX. EVIDENCE APPENDIX 

Appendix A was filed on June 6, 2005 as part of the Amendment After Final in response to 
a rejection argument first raised in the Final Office Action of May 3, 2005. 
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